RedisJSON 横空出世！

概述

近期官网给出了RedisJson（RedisSearch）的性能测试报告，可谓碾压其他NoSQL，下面是核心的报告内容，先上结论：

• 对于隔离写入(isolated writes)，RedisJSON 比 MongoDB 快 5.4 倍，比 ElasticSearch 快 200 倍以上。

• 对于隔离读取(isolated reads)，RedisJSON 比 MongoDB 快 12.7 倍，比 ElasticSearch 快 500 倍以上。

在混合工作负载场景中，实时更新不会影响 RedisJSON 的搜索和读取性能，而 ElasticSearch 会受到影响。以下是具体的数据：

• RedisJSON* 支持的操作数/秒比 MongoDB 高约 50 倍，比 ElasticSearch 高 7 倍/秒。

• RedisJSON* 的延迟比 MongoDB 低约 90 倍，比 ElasticSearch 低 23.7 倍。

此外，RedisJSON 的读取、写入和负载搜索延迟在更高的百分位数中远比 ElasticSearch 和 MongoDB 稳定。当增加写入比率时，RedisJSON 还能处理越来越高的整体吞吐量，而当写入比率增加时，ElasticSearch 会降低它可以处理的整体吞吐量。

查询引擎

并且，我们每次发行新版本时时，也在不断的提升性能。特别是对于reresearch来说，2.2版本在加载和查询性能上都比2.0快了1.7倍，同时还改进了吞吐量和数据加载的延迟。

1.加载优化

接下来的两个图显示了运行纽约市出租车基准测试的运行结果。该基准测试测量了吞吐量和加载耗时等基础数据。

从这些图表中可以看出，每一个reresearch的新版本都有一个实质性的性能改进。

2.全文搜索优化

为了评估搜索性能，我们索引了590万篇维基百科摘要。然后我们运行一个全文搜索查询面板，得到的结果如下图所示

从上面的图可以看出，通过从v2.0迁移到v2.2，同样的数据，在写、读、搜索(延迟图)方面都有了大幅度的改进，从而提高了运行Search和JSON的可实现吞吐量。

和其他框架的对比

1. 基准测试

此次测试，我们使用了如下的一些软件环境：

• MongoDB v5.0.3

• ElasticSearch 7.15

• RedisJSON (RediSearch 2.2+RedisJSON 2.0)

此次是在Amazon Web Services 实例上运行基准测试，这三种解决方案都是分布式数据库，并且最常用于生产中的分布式方式。这就是为什么所有产品都使用相同的通用 m5d.8xlarge VM 和本地 SSD，并且每个设置由四个 VM 组成：一个客户端 + 三个数据库服务器。基准测试客户端和数据库服务器都在处于最佳网络条件下的单独 m5d.8xlarge 实例上运行，将实例紧密地打包在一个可用区内，实现稳态分析所需的低延迟和稳定的网络性能。

测试是在三节点集群上执行的，部署细节如下：

• MongoDB 5.0.3：三成员副本集（Primary-Secondary-Secondary）。副本用于增加读取容量并允许更低的延迟读取。为了支持对字符串内容的文本搜索查询，在搜索字段上创建了一个文本索引。

• ElasticSearch 7.15：15 个分片设置，启用查询缓存，并为 2 个基于 NVMe 的本地 SSD 提供 RAID 0 阵列，以实现更高级别的文件系统相关弹性操作性能。这 15 个分片为我们为 Elastic 所做的所有分片变体提供了可实现的最佳性能结果。

• RedisJSON*：RediSearch 2.2 and RedisJSON 2.0: OSS Redis Cluster v6.2.6，有27个分片，均匀分布在三个节点上，加载了RediSearch 2.2和RedisJSON 2.0 OSS模块。

2. 100% 写入基准

如下图所示，该基准测试表明，RedisJSON* 的摄取速度比 ElasticSearch 快 8.8 倍，比 MongoDB 快 1.8 倍，同时保持每个操作的亚毫秒级延迟。值得注意的是，99% 的 Redis 请求在不到 1.5 毫秒的时间内完成。

此外，RedisJSON* 是我们测试过的唯一一种在每次写入时自动更新其索引的解决方案。这意味着任何后续的搜索查询都会找到更新的文档。ElasticSearch 没有这种细粒度的容量；它将摄取的文档放在一个内部队列中，并且该队列由服务器（不受客户端控制）每 N 个文档或每 M 秒刷新一次。他们称这种方法为近实时 (NRT)。Apache Lucene 库（它实现了 ElasticSearch 的全文功能）旨在快速搜索，但索引过程复杂且繁重。如这些 WRITE 基准测试图表所示，由于这种“设计”限制，ElasticSearch 付出了巨大的代价。

结合延迟和吞吐量改进，RedisJSON* 比 Mongodb 快 5.4 倍，比 ElasticSearch 快 200 倍以上，用于隔离写入。

3. 100% 读取基准

与写类似，我们可以观察到 Redis 在读取方面表现最佳，允许读取比 ElasticSearch 多 15.8 倍，比 MongoDB 多 2.8 倍，同时在整个延迟范围内保持亚毫秒级延迟，如下表所示。

在结合延迟和吞吐量改进时，RedisJSON* 比 MongoDB 快 12.7 倍，比 ElasticSearch 快 500 倍以上，用于隔离读取。

4. 混合读/写/搜索基准

实际应用程序工作负载几乎总是读取、写入和搜索查询的混合。因此，在接近饱和时了解由此产生的混合工作负载吞吐量曲线更为重要。

正如您在图表中所看到的，在 RedisJSON* 上不断更新数据和增加写入比例不会影响读取或搜索性能并提高整体吞吐量。对数据产生的更新越多，对 ElasticSearch 性能的影响就越大，最终导致读取和搜索速度变慢。

ElasticSearch 可实现的 ops/sec 从 0% 更新到 50% 的演变，我们注意到它在 0% 更新基准上以 10k Ops/sec 开始，并受到严重影响，减少了 5 倍的 ops/sec，在50% 更新率基准。

与我们在上述单个操作基准中观察到的类似，MongoDB 搜索性能比 RedisJSON* 和 ElasticSearch 慢两个数量级，MongoDB 的最大总吞吐量为 424 ops/sec，而 RedisJSON* 为 16K 最大 ops/sec。

最后，对于混合工作负载，RedisJSON* 支持的操作数/秒比 MongoDB 高 50.8 倍，比 ElasticSearch 高 7 倍。如果我们将分析集中在混合工作负载期间的每种操作类型的延迟上，与 MongoDB 相比，RedisJSON* 可将延迟降低多达 91 倍，与 ElasticSearch 相比，延迟降低 23.7 倍。

5. 完整延迟分析

与测量每个解决方案饱和之前产生的吞吐量曲线类似，在所有解决方案通用的可持续负载下进行完整的延迟分析也很重要。这将使您能够了解对于所有已发布操作在延迟方面最稳定的解决方案是什么，以及哪种解决方案不易受到应用程序逻辑引发的延迟峰值的影响（例如，弹性查询缓存未命中）。如果您想更深入地了解我们为什么要这样做，Gil Tene 提供了延迟测量注意事项的深入概述。

• 查看上一节的吞吐量图表，并关注 10% 更新基准以包含所有三个操作，我们做了两种不同的可持续负载变化：

• 250 ops/sec：比较 MongoDB、ElasticSearch 和 RedisJSON*，低于 MongoDB 的压力率。

• 6000 ops/sec：比较 ElasticSearch 和 RedisJSON*，低于 ElasticSearch 压力率。

1 MongoDB 与 ElasticSearch 与 RedisJSON* 的延迟分析

在下面的第一张图片中，展示了从 p0 到 p9999 的百分位数，很明显，在每次搜索时，MongoDB 的表现都远远优于 Elastic 和 RedisJSON*。此外，关注 ElasticSearch 与 RedisJSON*，很明显，ElasticSearch 容易受到较高延迟的影响，这很可能是由垃圾收集 (GC) 触发器或搜索查询缓存未命中引起的。

RedisJSON* 的 p99 低于 2.61 毫秒，而 ElasticSearch p999 搜索达到 10.28 毫秒。

在下面的读取和更新图表中，我们可以看到 RedisJSON* 在所有延迟范围内表现最佳，其次是 MongoDB 和 ElasticSearch。

RedisJSON* 是在所有分析的延迟百分位数上保持亚毫秒级延迟的唯一解决方案。在 p99，RedisJSON* 的延迟为 0.23 毫秒，其次是 MongoDB 的 5.01 毫秒和 ElasticSearch 的 10.49 毫秒。

在写入时，MongoDB 和 RedisJSON* 即使在 p99 时也能保持亚毫秒级的延迟。另一方面，ElasticSearch 显示出高尾延迟（> 10 毫秒），这很可能与导致 ElasticSearch 搜索峰值的原因 (GC) 相同。

2. ElasticSearch 与 RedisJSON 的延迟分析

专注于搜索操作，ElasticSearch 和 RedisJSON* 以个位数 p50 延迟开始（p50 RedisJSON* 为 1.13 毫秒，而 ElasticSearch 的 p50 为 2.79 毫秒），其中 ElasticSearch 付出了 GC 触发和查询缓存未命中的代价在较高的百分位数上，在 >= p90 百分位数上清晰可见。

RedisJSON* 将 p99 保持在 33 毫秒以下，而 ElasticSearch 上的 p99 百分位数为 163 毫秒，高出 5 倍。

来源：blog.csdn.net/xiangzhihong8/article/details/121530019

Java技术交流群

有不少同学问我，大厂面试官到底喜欢问什么？想进大厂镀金。因此，我特意邀请了华为、腾讯、阿里的朋友进群，与大家一起交流经验，增长技术。

有兴趣入群的同学，可长按扫描下方二维码，一定要备注：城市+昵称+技术方向，根据格式备注，可更快被通过且邀请进群。

▲长按扫描

近期热文推荐

点个在看你最好看